@Stealthii said outside of a thread:

To address one of the main criticisms I have with this MSC: the suggestion of matching specifically this tag: <strong\s+data-mx-profile-fallback(?:="")?\s*>([^<]+): </strong\s*>

If we are recommending regular expressions, I would suggest the following, which is safer, handling multi-line input, other tags, matching the same closing tag, etc.

input = input.replace(/<(\w+)[^>]*\bdata-mx-profile-fallback\b[^>]*>[\s\S]*?<\/\1>/g, "")

This however is not 100% safe, no regular expression is. Personally I would like to argue for non-fallback content to be explicitly stated in that MSC in a separate property field, because regex should be used for matching, not content manipulation in matrix client or bridge implementations.

Similarly, suggesting trimming the plaintext component by "PMP name length + 2" also assumes that clients implement the spec accurately as it stands today, and do not deviate. This also cannot be guaranteed.

Personally I would like to argue for non-fallback content to be explicitly stated in that MSC in a separate property field

Duplicating the entire content is a really bad idea. Each fallback doubles the content, so if there are 3 different fallbacks (edits, formatting, per-message profiles), that'd result in 2*2*2 = 8 duplicates of the content. It might be "only" 6 duplicates if the non-fallback per-message profile is only inside m.new_content, but if anyone decided to invent a new thing needing a fallback copy, it'd jump to 12 or more

which is safer, handling multi-line input, other tags, matching the same closing tag, etc.

The regex is intentionally fairly strict, other tags are not meant to be allowed. It could maybe slightly be relaxed in terms of the trailing space inside the fallback to allow \n there (<br> is obviously not allowed), perhaps :\s* instead of :

Alternatively, I guess the fallback itself could be put in another field, such that clients can simply do formatted_body.replace(fallback, "") rather than using a regex 🤔

Similarly, suggesting trimming the plaintext component by "PMP name length + 2" also assumes that clients implement the spec accurately as it stands today, and do not deviate. This also cannot be guaranteed.

The only consequence of deviating from the spec is that the message will render incorrectly. If clients don't implement the spec correctly and their messages render differently than they intended, that's their problem, not the spec's.

It would be really useful to have the fallback without making it confusing for users which might see those.

Similarly if the original username and the fallback is the same it doesn't make much sense to have both. Not sure if that's possible but it would cause less frictions with clients which don't support per message profiles.

Not sure how that's related to this thread, but fallbacks are already completely optional. Clients can freely omit the fallback when sending messages if they don't think it provides any value.

clients who don't handle per message user names, display usernames twice even if the senders username outside of that message would be the same, when receiving them from clients who do send fallbacks.

As I just said, clients don't have to include a fallback. If the sending client notices that it's going to send a per-message profile with the same name as the user's global profile (e.g. because only the avatar is changed), it can simply skip adding the fallback. The fallback is completely optional, so the choice of whether to include it is up to the sender.

I think it would be good if the HTML fallback could include the per-message avatar as well as the username. This could be done with an img tag per the custom emojis specification.

Example: <strong data-mx-profile-fallback><img width=48 height=48 data-mx-emoticon src="mxc://example"> username: </strong>

Avatars are important for building mental associations of individual users. I think this would greatly improve people's understanding of the messages if they are using a client that doesn't support this MSC.

I don't think the MSC is going to suggest that, users who want to understand messages better should use a client that supports per-message profiles. However, if the fallback removal was done using a string replacement instead of regex (as mentioned in the thread above this one), then the sender could technically add images as an implementation detail.